home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 8965 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.6 KB
  1. Path: zk2nws.zko.dec.com!usenet
  2. From: Webb Scales <scales@zko.dec.com>
  3. Newsgroups: comp.programming.threads,comp.lang.c++,comp.unix.osf.osf1,comp.unix.programmer,comp.object
  4. Subject: Re: Looking for best design for using pthreads in C++ objects
  5. Date: Mon, 26 Feb 1996 14:16:21 -0500
  6. Organization: Digital Equipment Corporation, DECthreads
  7. Message-ID: <31320705.41C6@zko.dec.com>
  8. References: <3128ff8b.666031216@news.clark.net> <312A0E5F.7B2C@ix.netcom.com>
  9. NNTP-Posting-Host: chook.zko.dec.com
  10. Mime-Version: 1.0
  11. Content-Type: text/plain; charset=us-ascii
  12. Content-Transfer-Encoding: 7bit
  13. X-Mailer: Mozilla 2.0 (X11; I; OSF1 V3.2 alpha)
  14.  
  15. David Brownell wrote:
  16. > One of the really nice techniques is to have a "Locker" class to grab mutexes
  17. > as needed, and then release it automatically on all exits.  [...]
  18. > That kind of class really helps get rid of the bugs you have due
  19. > to locks not getting released uniformly on all codepaths.
  20.  
  21. Hmmm...this approach makes me nervous.  I assert that it's better to neglect to
  22. unlock a mutex than to unlock it when you shouldn't have.  
  23.  
  24. For instance, if a thread holding a mutex via the "Locker" class terminates
  25. prematurely (due to an exception or cancellation), then the mutex will be
  26. unlocked automagically, despite the fact that whatever it was supposed to
  27. protect is now likely to be in an inconsistent state.  If the process manages
  28. to survive losing this thread, then any subsequent accesses to the shared data
  29. could easily be disastrous in subtle ways.  It would have been much better to
  30. have just left the mutex locked!  (That is, a deadlock would be much easier to
  31. debug than a memory corruptor.)
  32.  
  33. The missing piece is that the destructor for Locker, prior to releasing the
  34. mutex, must restore the shared data that the mutex protects to a consistent
  35. state.  In order to do this, the destructor requires intimate knowledge of what
  36. the lock is protecting -- this invalidates the "generic" approach.
  37.  
  38. It would be much better to encapsulate the mutex together with the shared data
  39. as some sort of compound object.  Then it would be feasible to have the proper
  40. clean-up built in.  And then it would be OK to be unlocking the mutex
  41. automagically.  :-)
  42.  
  43. -- 
  44. ------------------------------------------------------------------------
  45. Webb Scales                                Digital Equipment Corporation
  46. scales@wtfn.enet.dec.com                   110 Spit Brook Rd, ZKO2-3/Q18
  47. Voice: 603.881.2196, FAX: 603.881.0120     Nashua, NH 03062-2711
  48.          Rule #12:  Be joyful -- seek the joy of being alive.
  49. ------------------------------------------------------------------------
  50.